This invention is related in general to digital networks and more specifically to providing authentication services in association with a transmission control protocol.
Security plays an important role in exchanges of information in digital networks. Because of the prevalent use of networks such as the Internet, corporate and campus intranets, local area networks (LANs), etc., valuable and sensitive data is often transferred in way that might make the transferred data accessible to unwanted or unauthorized “attackers.”
One way that the prior art attempts to prevent unauthorized access to data is to require a user or device seeking access to information to authenticate the user or device's identity. For example, a popular Extensible Authentication Protocol (EAP) includes authentication mechanisms that are used by popular networks such as the wireless network standard specified by the 802.1×type of networks (i.e., “WiFi”), IEEE 1394 (i.e., FireWire), etc. Other networks and protocols also use EAP-based authentication. See, e.g., “PPP Extensible Authentication Protocol (EAP),” L. Blunk, J. Vollbrecht, Request for Comments: 2284, March 1998.
The EAP approach uses an Authentication Server that is consulted by an access point device. The access point device can be, e.g., a wireless access point from which a user, or client, must seek access. The access point device controls access to information by allowing users only limited access (e.g., via restricted ports) to information on a network. Once a user is authenticated then the user is placed onto a port with less restrictions and greater access.
To obtain access, a user device requests an EAP handshake from the access point. The access point establishes a port for EAP-only traffic and asks the user device for an identity (e.g., of the device, client, etc.). The user device supplies the requested identity. The access point then contacts the Authentication Server with the identity. The Authentication Server checks the identity against a database (e.g., by comparing a supplied password to a list of passwords and IDs) and responds with authentication approval or denial. The access point then grants access accordingly.
Although some existing protocols and standards successfully support integrated authentication there are other protocols that do not have the benefit of having been developed initially with authentication mechanisms in mind, or that are not readily equipped to support adequate authentication and other security features. Many protocols are not secure and permit plaintext (or base64 encoding) credentials to be transmitted through the network. When such protocols are extended to later support authentication, such authentication extensions are typically limited in their ability.
For example, the popular Transmission Control Protocol/Internet Protocol (TCP/IP) is an older, widespread standard transport protocol for exchange of information over the Internet. It is desirable to improve security features, such as authentication, to the TCP/IP protocol because of its prevalence, popularity and support within the existing Internet infrastructure and community.
One drawback with traditional authentication methods using TCP/IP is that a regular TCP/IP session is established before authentication starts. Therefore, TCP resources are already in use before a session is authenticated and this could be an exploited weakness. Also, in typical applications where a centralized Authentication, Authorization and Accounting (AAA) server is used, some of the authentication takes place at the application protocol level, requiring bridging between application protocols and AAA protocols that can represent another weakness.
Before a TCP/IP transfer of information occurs, a connection is established. The connection is established using a so-called “three-way handshake.” FIG. 1 illustrates, a three-way handshake between a TCP client process seeking to establish a connection with a TCP server. In FIG. 1, the client sends a TCP segment including a synchronization flag to the server (SYN==1).
The synchronization segment requests the server to synchronize to the client's sequence number, N1. In a second step, the server responds with a segment including an acknowledgement using the sequence number sent from the client incremented by one (N1+1). The server's segment also includes a request for synchronization to the server's sequence number, N2. Finally, in a third step, the client sends a segment including an acknowledgement using the server's sequence number incremented by one (N2+1). The client's acknowledgment of the server's request for synchronization completes the process of establishing a reliable connection by using the three-way handshake.